/ok to test 207fab3

/ok to test cddb787

Thanks @nguidotti . I took a brief pass at this PR.

My biggest comment is that after this PR, I find it very hard to reason about the lower bound. We've had many bugs where the lower bound is incorrect or lost. I'm concerned that unless we make the handling of the lower bound as clear as possible to follow there will be more bugs. There are so many places in the code that now track the lower bound. For instance, there is a lower bound member in the node_queue_t. There is a lower bound member in bfs_worker_t (really in branch_and_bound_worker_t), there is a local variable named lower_bound in best_first_search_with there is a function called get_lower_bound, there is the lower bound ceiling.

Is there anyway to simplify this? For instance, do we need to have the lower bound stored in the node_queue_t and the worker? Could we only store it one place?

Can we make clear the comments around temporarily setting the lower bound?

Unfortunately, no.

Let forget the parallel execution for a moment. When we are doing best-first search with plunges, there are two places where we need to consider the lower bound: the top of the heap (worker->node_queue.get_lower_bound()) and the node that is currently being solved (worker->lower_bound). At the start of the plunge, we pop the best node from the heap, such that the heap does not contains the lowest lower bound anymore. As we do the plunge, the lower bound of the node that it is being currently solved changes and can become worse than the new top of the heap. To avoid locking the queue just for reading the lower bound, I simply use an atomic to track it, which read when call worker->node_queue.get_lower_bound().

For computing the lower bound for the entire solver, you take
$$L_{global} = \min_k L^{(k)}, \qquad L^{(k)} = \min{L_{heap}^{(k)}, L_{cur}^{(k)}}$$
where $L_{heap}^{(k)}$ is the lower bound from the top of the heap and $L_{cur}^{(k)}$ is the node from the node being currently solved. The k subscript denotes the worker $k$.

There are other things, we also need to consider. For instance, we might encounter a numerical issue in a given node, which blocks the solver to progress further down that path. Similarly, starting a new worker or stealing a node, the node needs to be transferred from one worker to the next (pop, then push the best node in the heap). In the meanwhile, the lower bound of that node needs to be store somewhere so it can be considered when computing the global lower bound.

I tried to concentrate all the global lower bound computation in the get_lower_bound in B&B, but some of the values are set during the exploration

/ok to test 02d0381

/ok to test e212f63